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@ Socket structure for concurrent multiple protocol access. 

@ In a multlprotoool environment, a new socket 
fitnjcture Is provided which moves the decision 
on which protocol to use until the time that the 
oonnection Is actually made t>etween nodes In 
the netwoik. The new socket atmcture Is 
created for every endpolnt, All the pfotocols 
which could potentially be used to eend or 
receive data is sent a request lo create a pro- 
tocol control btock at the time the new socket Is 
created. A seJection process detemilnea which 
of the protoools oould be used by the endpolnt 
The new socket then contains information on 
each selected protocol. At the time a connec- 
tion is established, any of the selected protocols 
oould be used. The choice of which protocol to 
use can be based on user preferences, which 
protocols ere avail^le, the name of the service 
unit 
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BACKGROUND OF THE INVENTION 

This invention rotates generally to data communication in a network of computer systems. Mcjre particu- 
larly, it relates to a communication endpoint structure which enables applicdtion programs resident on systems 
5 to communicate through such a network in^spective of the protocol for whch the applrcaiion was wrttten and 
the protocols avallat^le on the network. 

Once upon a time, olnmst all computer systems were standalone processors to which private peripheral 
devices such as displays, printers and disk drives ware oonneded, acting independently from any other com- 
puter system. Yet, It became apparent that there were substantial gains to be made If several computer sys^ 
10 terns couJd be ooopsratlvely coupled together. Today, it has become commonptsce to couple a multitude of 
computer systems into a distributed environment such as a local area or wkie area network 

Howeverp there are many vendors who have dsveloped their own hardware and software solutions for in- 
tegrating multiple computer systems. In particular, they have developed different ideas of the format and pro- 
tocofs that should be followed In transporting data through the networks. Some protocols support expedited 

19 data transmission by bypassing the standard data flow controls; others require all data to go through the con- 
trols. Specialized protocols are used fbr transport tasks such as establishing and terminating connections be- 
tween computer systems. Examples of weD known communication protocols include System Network Archi- 
teoture (SNA). Digital Network Aithitdcture (DECnet), Transmission Control Protocol/Internet Protocol 
(TCP/IP), Network Basic Input/Output System (Ne^lOS). Open Systems Interconne<dIon (OSi) and AppleTalk. 

20 Other protocols are known and widely used. 

Most distributed applicatnn programs are written to an application programming Interface (API) which as^ 
surt^es a particular communlcettona protocol IHowever, the distributed environments which most organbiatior^s 
have assembled are quite compldx, comprised of confedemttons of indivlc^al networks running different com- 
munication protocols. If the transport protocols assumed by the distributed applicatk^n's API and the transport 

2$ protocols actually implemented in one or more of the networks on which the organization would like to send 
its data are not the same, the use of the application is llmfted. The problems of such heterogeneity in commu- 
nicattons protocols Is expected to get worse as more organteatlons begin to communicate with each other 
through their networks to perform order processing, direct billing or other cross organization activities. 
While the distributed appiicaftiona could be rewritten so that they can ran over each transport protocol or 

30 applicatk)n gateways can be written for each distributed of dlstribulied applications, the cost of having pro- 
grammers write all the necessary code makes these approaches economically unattractive. A preferred soiu* 
tion is presented 'm copending application, Serfel No. 731,584. entitled '^Compensatk)n for Mismatched Trans- 
port Protocols In a Data Communications Network^ by R.R Bird et al, filed July 1 7. 1 991 and hereby incorpo- 
rated by reference. The incorporated appltcatfon teaches a traruport connection layer between a first transport 

36 user at one node In the network and e second transport user at a diffarant node In tha network. When tha 
transport protocol assumed by tha applrcatton at the firat node is not available in the network, the data being 
transferred between the two nodes Is automatically altered to be compatible with the available transport pro- 
tocols. Thus, an organization is able to choose application programs solely on the basis of the functions they 
provide, rather than the protocols which th^ require. 

40 The above referenced eppl|catk)n teaches a generalized transport layer. One of the transport structures 
which is presently usad in tha Berkeley version of tha UNIX(TM)environmBnt is called a socket Asocket Is an 
object that identifies a communication endpoint in a network. A socket hides the protocol of tha network ar- 
chitecture beneath from the applicatfon. A socket allows the association of an endpoint, such as an application 
program, with one of the selected protoools. This association occurs whan tha eiKlpoint is created. An endpoint 

49 craatlon implies a static association of the socket with the protocol, which will remain invariant However. In a 
multiprotocol environment, as described in the above referenced sppllcation, whtoh facilitates hatarogensous 
connecth/lty, a transport endpoint may need to be bound to any of several connectivity, a transport endpoint 
may need to be bound to dr»y of several available protoools after the creatkin of the endpoint. Therefore, If 
sockets are to be used in such an envin>nment a new socket structure which allows dynamic association of 

so the socket with the protocol must be devised. The present inventton teaches such a socket structure. 

Summary of the Invention 

The present invention provides a system and a method for communicating ttetween nodes In a oomputar 
69 network in which a plurality of protoools are useable by network nodes, the method comprising tha steps of 
creating communication endpoint objects defining communication parameters for respective network nodes, 
the objecta having information about the plurality of protocols whiidn are useable bv said noda for Inter-node 
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between said nodes using a selected one of the piurallly of protocols. 

The present Invention thereby fecilltates late binding of an endpoint to a transport protocol in a distributed 
environment, enabling a more dynarnic association between protocol and endpoint. 

Preferably, the Invention allows native aocess to a protocol by an application. It is also prafen^d that the 
6 invention provides the necessary mibnriation for norv-natlve connections to a protocol. 

The Invention provideB, in a preferred embodiment a new socket stmcture which moves the decision on 
which protocol to use to the time that the connection ie actually made between nodes in the network. In a mul- 
tiprotocol network, the new socket structure can be created for every endpoint For all of the protocols which 
could potentially be used to send or receive data a request Is made to create a protocol control block at the 
10 time the new eocket Is created. Aseleaton process determines which of the protocols could potentially ba used 
by a given endpoJnt The new socket for the endpoint then contains Information on each of the selected pro- 
tocols. At the time a connection is established, any of the selected protocols oould bo used. Native or non- 
native oonnecttons can be made. The choice of which protocol to use or the order of protocol preference can 
be based on user preferences through configuration, the local cache, or information from the named service 
1$ unit 

Brief Description of the Drawlnfla 

The invention wi 11 now ba described in more detai I. by way of example, with reference to the accompanying 
20 drawings In which: 

FIG. 1l9 a diagram of two single protocol networtcs coupled together through a multiprotocol transport net- 
work. 

FIG. 2 is a block diagram of the transport intarfeice used according to an embodiment of the present In- 
ventk>n. 

2s FIG. 3 is a diagram of a conventional eocket control block. 

FIG. 4 is a diagram of the socket control block according to an embodiment of the present invention. 

FIG. 5 Is a flow diagram of the creatton of a socket ecoording to an embodinrwnt of the present Invention. 

FIG. 6 Is a flow diagram of establishing a connection in a muittprotoooi transport network environment, 
using a muiUprotocoi socket according to the Inventmn. 
30 FIG. 7 is a representation of a computer system including system unit, keyboard, mouse and display. 

FIG. B is a block diagram of the computer system components depicted In FIG. 7. 

Detailed Description of iha Drawings 

SB The following descriptkui descflbas a socket based architecture. However, the invention is not limited to 
sockets and could be applied to similar communication endpoint objects in other operating systems. 

Although the tbOowing description contains an adequate disdosuns of oonvantronal socket and network 
architecture to allow one skilled in the art to understand the present invention, the reader is referred to TTie 
Design and Implementation of the O BSD UNIX Qperatino System by S. J. teffer at al,. 1 &89 which is hereby 

40 incorporated by reference, for a nr>ore complete understanding of operating system based on the Berkley ver- 
sion of UNIXTM. Such operating systems are weH known. 

FIG. 1 shows three single protocol networks 10, 12, 14 which are Interconnected through a gateway 59 
built according to the principles of the present Invention. With the growth of network distributed environments, 
it is not uncommon to see networlcs using four or five different pratoools, such as TCP/IP, NetBIOS, SNA or 

45 AppieTAUC Since applications which run on one network will not often run with applications on the other, trans- 
port of data throughout the network Is hindered. As discussed above, the Multiprotocol Transport Network 
(MPTN) 16 as taught in the above referanced appllcattan addresses these problems by defining en interface 
and a compensation mechanism to a set of transport services that provide oonnecttons across a plurality of 
transport protocols. By providing a transport boundary between the netwoiks and the applications resident 

50 on systems, MPTN provides a common transport Interfiaoe so that ntessagea from the applications can be 
transported over any protocol in the network. 

As shown in FIG. 1 , hosts 20 and 22 are coupled to the multiprotocol transport network 1 6. Whi is the MPTN 
16 appears as though it is a single logical network having a single protocol, host 20 is coupled to a f Iret network 
10 which communicates via protocol X e.g., TCP/IP, and host 22 is coupled to a second network 12 which 

66 communicates via protocol Y, e,g„ NetBIOS. 

Application program A24 resident in one of the hosts 20 coupled to the MPTN network 16 wishes to com- 
municate to application B 28 resklont in another host 22 also coupled to the network 16. Upon applk^ation A's 
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Sockets contain infbrmation about their type, the supporting protocols used In the transport leyer 28 and Iheir 
$tQte. A connection requestgoes through the traneport layer 26^ the network Iayer2d and the network Interface 
layer 30 which add tha necessary control and date Information before the message is sent out on the network 
54. Compensation for the dlfferenoas between protocol y and X is carried out by the transport layer as taught 

9 by the above referenced application . 

FIG, 2 depicts the code modules in memory at a oomputer system which is coupled to the multiprotocol 
transport network in greater detail. The socket programming interfaoe 60 and common transport semantics 
62 ocHTospond to the socket layer and separate the applicatkms G4, 66, 66 from the service drivers 70, 72, 
74. Three types d applications 64. 66. 68 are shown in the apptloatlon layer. To utilize the socket structure of 

10 the present invention, NetBIOS applications would be rewritten to the socket API to become the NetBIOS sock- 
et application 66. The standard local IPC socket application 64 and TCP/IP applications 68 are afraady written 
to a standardized socket programming interfaice and so would raqulre an minimum of revisions. The common 
transport semantics 62, include the socket control blocks, which will be described In greater detail below. An 
Interface between the socket layer end the transport layer is comprised by the local IPC service driver 70, the 

13 NetBIOS service driver 72 and the INst service driver 74 which correspond to the appltcatlonG in the application 
layer. The service drivers are used to emulate the common transport semantics for the transport protocol driv- 
ers In the transport layer In the present invention, they may also contain the compensating means dasorlbad 
In the above referenced appUcation which converts a message intended for a first protocol by the application 
to a second protocol supported by the network. The transport layer indudea the NetBIOS 76 and TCP/IP 76 

20 protocol drivers which cause the application message to conform to the prolocol format There is no corre- 
sponding local IPC module as It describes a local protocol whose messages are not placed on the neh^ork. 
The network and network interface layers are not pictured, the latter would Include device drivers for the I/O 
hardware which couples the computer system to the network, e.g. a token ring or ethernet drtvar the former 
might Include drivers written to the well known NDIS Interface. 

25 A socket Is the object in the Berkeley verston of UNIX(TM) from which messages are sent and moeived. 
Sockets are creetad within a commun ication domain as files are created wtthJn a file systera Acommunication 
domain summarizes the sets of protocols, the naming conventions, the hardware which may be a particular 
netwofk and may use an address whksh refers to the communication domain. The internet domain specified 
by the address family AFJNET; the NetBIOS domain is refer&nc5ed by the addr^ family AF_NETBIOS,Acon- 

30 nection is a means by which the identity of the sending socket is not r^uired to be sent with each packet of 
data. The Identity of each communication endpofnt Is exchanged prior to any transmission of data and is main- 
tained at tlie transmitting and receMng nodes, so that the distributed appjlcatlons at each end can request 
the socket information at any time. 

When an application creates a socket endpoint for a certain protocol and the protocol chosen by the trans- 

35 port network matches that protocol, natrve networking has occurred. For example, the INet protocol is used 
to support the INet address family end NetBIOS suppcrta the NetBIOS address family. On the other hand, 
when the transport protocol does not match the socket endpoint of an applicatton it is termed non-native net- 
working. Using the preaent invention, however, the application is unaware that a different transport protocol 
is being used to connect with other nodes In the network. 

40 In the present invenilon, the socket interface Is used to connect between replicas of a distributed appli- 
catnn or tha client and server portions of a clfent/server application using a variety of transport protocols. The 
application can select the transport protocol or request that the socket layer delemnlne the protocol. With the 
non-native networking feature of tha present Invention, applicetions written to oomnuinicate with one another 
using one pratoool can choose to oommiinloate on another transport protocol whkrh might be optimized for the 

45 network environment For example, an applicatton written fOr TCP/IP could communicate using the NetBIOS 
protocol over the nQtwork*ghring the distributed applicatfon a signtHcant performance gain. 

A conventional socket control block is depicted in FK^ 3, e sodcet control block 100 contains Information 
about the socket, including send and receive data queues, their type, the supporting protocol, their state and 
socket Identif far. The socket control block 100 includes a protocol switch table pofnter 104 anda protocol con- 

so trol block pointer 106. The pointers are used to locate the protocol switch table (not pictured) and the protocol 
control block 102 respectively. The protocol swftch table contains protocol related information, such as entry 
points to protocol, charactertstlos of tho protocol, certain aspects of its operation which are pertinent to the 
operation of the socket and so forth. The socket layer interacts with a protocol in the transport layer through 
the protocol switch table. The user request routine PR_USRREQ is the interface between a pnotocol end the 

ss eockst The protocol control block contains protocol specific infbrmation which Is usod by the protocol and Is 
dependent upon the protocol. 

Asocket control Mock according to the present invention is shown in FKB. 4. Here, the socket control block 
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tional socket control block above end the MPTN extension 112 which oontalns many of the feaiorea necessary 
for the present Invention. Both are linked together by a multiprDtoool transport network extension 113. Each 
of the protocols which could be potentially used to send or receive data is sent a request to create a protocol 
control block 120, 122 at the time the new socket is created. After a selection procedure, the new socket then 
5 contains information regarding each selected protocol, the protocol swSch table pointer 114. 116, the protocol 
control block pointer 11 6. 119, and a pointer to a interfiace address if applicable for the particular protocol (not 
pictured). As above, the protocol switch table pointer refera to a respecttve protocol switch table which defines 
vanous entry points for that protocol. Also, the ;^tocol control btocks 120, 122 contain protocol spedfk^ in- 
formation. 

10 At the time of socket creation, no connection is made to any particular protocol to the application sndpolnt. 
Connection 1 mpPes an association of the connection-requestor socket of the requesting application lo another 
connection-acceptor socket. It can be viewed as a communication wire running between the two sockets that 
are "connected", potentially in two different continents, providing the abi lity ^r both of them to eend and receive 
messages. There is no difference between a transmitting socket and arecetving socket for the pnssent inven- 
ts tlon . After a connection, each can send or receive data. 

The decision on which protocol to use is delayed until ttie time that the connection is actually made. At 
the lime of establishing a connection, any of the network Interfaoes In a protocol coutd be used. The order in 
which the pointers which refer to the protocols and network interlieices is based on user preference, Infbnnr^ation 
from the named service unit or the capability of the protocol the socket extension 1 1 2 which oon tains the poin- 
20 tsrs 1U, 116, 118 and 119, also Includes state information on the socket and the multiprotocol transport net- 
work. The socket extansk^n 112 is used by the socket layer to manage the socket and MPTN states. From the 
list of available protocols, the socket layer pkdcs those protocols that support the requested socket domain and 
the type of oommunlcalton (datagrams, streams, etc), as described In the flow diagram for socket creation de- 
scribed betow. 

25 A sample socket control block structure Is given In the code below: 



30 



36 



40 



45 



GO 
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/* Bocketra.h 

* Kerne] structure per socket, 

* Contains oend and receive buffer queues. 

' landle on tirotx)ool and pointer to protocol 

* wlVflte data, error inforitakion and KPTN extensiona. 

* Tbe Ilrat bart of tliis structure ( upto the so iiptn field ) Is 

* to the BSMJ socket control block. 
*/ 

Btract pocket [ 

short 00 type^ 

abort 
filtott 
caddr t 
strucE 



identical 



BQ^options; 
Bojiiwer! 
Bo_Btatej 
60 DCb; 

prolo^v far *so_proto: 



/* generic type, see socket. h ♦/ 
/* fron Bockei call. $ee socket. h 
tive to linger virile closing ^/ 
/* Internal state flaqs Ssj, beiov */ 
/* protocol control block */ 
/* protocol handle */ 



* ?arlableB for connection gueuelng. 

* Socket iAer« accepts occur is so^bead In all eiibeidiary sockets. 

* If $o_head is D. socket is not related to at) accept. 

* for bead Kicket zojfi queues partially oohpleted Gonnectiona, 

* vfiile ao.g la a ^ue of connections ready to be accepted. 
^ If a oonnectlon is aborted and it bd( to h&d set, then 

* it has to be pulled out of either so.oQ or so.q. 

^ We ajjfitf connections to queae up based oti current queue lengths 
^ and IJilt on hunber of queued connections for this socket. 
V 



struct eocket far ^ao.head; 
struct rocket far *fio_qO; 
etrott socket far *fio g: 
short TO_g01en; 
short so.glen; 
short solqlinit; 
short sojiaeo; 
a_Bhort so_error; 
short 5oj)9rp; 
a.long Bo^oobiark: 
VariBbies for socket buffering 

struct Bockbuf [ 

ujong 8b_cc 
Oong 
ujong 
ujong 
a lona 
slnict 
struct 

short sb_tiiieo 
short sb^llAgs: 

} Bo^rcv, 50_snd; 

/• HPTO SOCm CTTEreiOH */ 

struct i.esock far * so.nptn: 



back pointer to accept eocket 
/* queue of partial connections */ 
queue of inconjng connections *f 
/* partials on so_qO •/ 
/* nuaber of connections or so q ♦/ 
iax nuiber queued connections */ 
/* connection tlneout */ 
/* error affecting connection V 



rarp for sionals V 
chars to ooS lark */ 



Bb^hivat: 
sblabcntj 
sb.abvax; 
sb^Jowat; 
nbuf far ^sb^nb; 



/* actual chars in buffer V 
/* tax actual char count V 
/* chars of Bbufs used V 

max chars of nbufs to u^e V 
/* loK vater mark (not used yet) 
/* the nhuf chain */ 



proc far ♦sb^selj /* process selecting read/vrite •/ 
" /* tiaeout (not used ycL) •/ 

f* flags, see belov */ 



Adefine 5B_KAX 
idefine SB \m 
tdeflne StTHAKI 
Hefine SbIvait 
idef ine SIJBL 
Iderine SB COLL 
1; 



C (oblong) (64M024[p» 
QkOI 
0x02 



OxOS 
0x10 



/* socket HPTH extensions */ 

/* nax chars in sockbuf •/ 
/• lock on data queue (so rev gnJy) */ 
/» soreone is vaiting to lock V 
/* Boiteone is vaitino for data/space V 
/' buffer is snlectcd ♦/ 
/* collision selecting V 



SDcket extenaions for mn 

* The socket control block points to this elmclure which contains 

* all the »TM related socket extensions. 

» Since iLesock. the (PHI cxtensjons to sockstB. is coatalned in one 

* »biif , ve could use the rest of rtnif space to aoconaodate the tttb 

* pointers. ^ 
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10 



16 



20 



defined the ebructnre for storing additional pointere. 

* used IQ i efioclc. 

" The strDOQre v.addr defines th& addrese forciatjt is defined In Bptndet.h. 
^ strnctnre b info defines the user specif iod connection character is tics 

* and is defined in iptndef .h. 

« The structore bnlst defines the aser configured protocol preference list 
^ and 19 delinsd in uptndef ,h, 

*/ 

struct iLSopcb { 

struct ptotosv far * eo_proto: 
caddr t so_pcb; 
struct P.addr far * so.bnsap; 



>: 

struct iLcottn^stat { 
char type: 

char index; 



caddr.t ftnao; 



/* protocol switch ptr 

/* pointer to the PCB V 

/* the wtwork interface 

* the PCB refers to */ 



/* DST BUSAF EOUND.USE FREF LIST.CACFE, 

* mjmjiw, GHJNSSP V" 

/♦ current nettforli,..»6 an inden in to the 
* preC. list as the case is. 
♦/ 

/* destination naiie..for ABH cnse. Gatcvay 

* cases, it U dst.bjiai, 

* In the native case or cache case. contains 

^ the dest A-addr 
V 



that 



25 



30 



35 



40 



45 



50 



55 



struct bnlet far *prflst; pointer to the pref list ^/ 



struct iLesQck ( 

int Bo^upcall ) 0: /* user upcail address '/ 
struct socket far * so.reJav; /* relay socket pointertfor gateway only V 
- - - - /« connection chars given at n create ()*/ 

/* conn. char of a connection V 
/* user specified don^in */ 

Jocal user naite */ 
/* peer user nane */ 
/• conncction/tenination data */ 
/* eHpedited data »/ 

/* linked list of nonnativA scbs.to search 

* for user^nanesV 

/* iiptn flags having the folloviDg def?*/ 
/* to paintain iiptn connect status */ 
/• nunber of pcbs currently in sopcti I *( 
pcb stateibit position corresponds to 

* pcb array; 0->ln-use; else not-in-uae*/ 
struct D.sopcb sopcb fKFTN HM(PCB1>/* array of n sopcb structures *f 



struct iLlnfo f^r 
struct n info far 
sbort BO^doiain; 
struct n.addr far 
struct iLsddr far 
struct ibuf far * 
struct ilAif far * 
struct Bodtet far 



» so^cinfo: 

* Bo.lanai; 

* 80_panaa; 
SO.ctdata; 
Bo.expdat: 

* Bo.neKt; 



unsigned SD_iptn_flag: 
struct p^oonn^stat conn atatj 
sbort sojcbnoit : 
long sojxbstat: 



Marine KFTOONHATIVB 0x01 

Mefine MFTOAnVE 0x02 

ftdefine IffTN SO BIHD Cn04 

Mefine KPTOO IMBIH) 0kO8 

idefine HPTO0.C0NH 0x10 



Mefine MPTH.SO.NOHOffi^COTW 0x20 

tdefloe HFnLS0_MStfi»l 0x40 
Mefine )eriLSO.CON.HEAD_WAIT 0x80 

fdefine HPrN.60.CGN HSAD.RCVD QxOlOO 
Mefine )(T}LSO.CClLHBADJBn 0x0200 
Mefine WTILSO.OONJSTABEilSnEO Ok0400 
Mefine NPTH.SO.CLOSED 0x0800 
Mefine «PT)LSO_BCASrjlCY 0x3000 

Mefine KPTKjSOJK.ADM.AW 0x2000 



/* indicates nonnative contrection */ 
/* indicates native connection */ 
/* Mch ifitn Btate->addr bound */ 
/' sock iptn state- >addr not bound*/ 
/* sock hptn Btate«>connect reg is nadeV 
/• -Hbere Mill be no more conn. re*try 

* over other networksyprotocojs*/ 
/* init state of a p&ssjve sock */ 

native con set up..vaiting for HPTN 

* connect header ^/ 



/* baaeive RQde...mtn con rcvd, ,*/ 
/* Active nodc.nptn con sent 
/* Connection eBtablished ..,*/ 
/* local socket close issued */ 
i* the ftockefc is enabled to rev 
* hroadcast dgns.*/ 

f* the socket h bound to in_sddr_ahy »/ 
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* Socket Btate tuts. 
V 

Ufif iM SS.NQPOREF 
Mef iRO SSJSOONNBCTBD 




OxODl f* mo file table re£ any sore */ 

Oh002 /* wcket connected to a peer */ 
OkO(H h process of connecting to peer 

0x008 /* in pt(k»« of disconnecting */ 
OkOIO can't send rore daU to peer 

OsQlO /* can't receive rore data Iron peer */ 

0x040 /* at »ark on input */ 



5 




fdeftJie S CUirSSWHORS 



10 



tdeflne SS_PRIV 
ftfeMne SSJBIO 



0x080 prWileqed for broadcast, rav... */ 
OkIOO /• nofl'Wocliing ops •/ 
OrZOO /• 88710 i/o mtiiy V 



0x1000 /* cancel call */ 
OxeOOO /* em push V , 



_ Rest o£ the info h the sane as in the BSD4,3 socketva.b */ 

Copyright, IBH Corp. 1993 

Conventional socket creation starts with a catl to the socket API. Adomain table is searched for the address 
famil/p the type and protocol which is desired by tho application. If a match Is found the protocol switch tMo 

20 entry is set in the socket oontrol block. Next, the user requests entry and the aalected protocol is called to 
create of the ptotocol control block. If a nnatch la not found In the domain table for tho adc^ss temlly, type and 
protocol desired by the application^ an error ta returned to the application. 

FIG. 5 depfcts the process of aeatlng a socket acoordlng to the present Invention. The process begins 
with a socket creation request 150 from on application to the socket API, the application wishes to send or 

z$ receive data across the networks The command to the socket API for the request takes the form of sockQt=(AF, 
*, type, proto). *'AF" refers to the address fiamily and communication domain; *1ype'' refers to one of the socket 
types defined In a system headerf ile. The "proto* or protocol parameter '& used to Indicate that a specific pro- 
tocol is to be used. A test is performed in step 1 52 to determine if 'proto" is specified. If so, the normal socket 
crBatk>n process in step 154 Is cairled out and the process ends, step 155. 

30 If "proto* is not specified, the process continues to create a multlpFOtoool socket Each protocol is associ- 
ated with a protocol switch table. For each protocol switch table* step 155, testa are performed whether the 
type and address family of the requesting endpoint, steps 158 and 160. are matched by the protocoJ. In step 
158 the test for ^type** match Is performed. If the teat fails, the process returns fbr ths naxt protocol switch 
table, step 156. If the test succeeds, the test for address family match is performed in step 160. Both the type' 

99 and family" are represented as integers. By matching, the socket layer compares the *type' and "Address fkm- 
ii/* field supplied by the user and the type' arid "address family' fields in the protocol. If a matc^ found for 
both type and address fiamily. the protocol is selected as a candidate protocol and set in the socket extenston 
with pointers to the protocol switch table and protocol control block, step 162. If there Is no match, the process 
determines whether the addrass family is supported non-natively in the network, step 164. If the protocol is 

40 supported, step 166, the protocol is selected bs a candkiate protocol and set In the socket extension with poin- 
ters to the protocol switch table and protocol control block, step 162. If the protocol is not supported, in step 
1 66. a teat la perfbmied to determine whether it is the last protocol switch table, ff not, the process returns to 
step 1 56. If It is the last protocol switch table, the process ends, step 170. The protocol pointei^ can be raoidsrsd 
within the extension acoordlng to ^e application or user preference through the use of e configuretlon tool or 

45 acoordlng to Informatton from ^e named server. 

In FIG. 6, the process to establish a connection using the multlprotoool socket b described. The process 
begins in step 200 where the socket layer tries connecting to a specified destination using the first protocol 
from the list of protocols In the socket extension. The choice of which of the protocols to try firet can ba based 
on tha conf pgurstion of user specified preference order of protocols. If the connection succeeds, step 222, tlie 

SO process ends in step 223. If not, the next protocol is used to try to establish a connection in step 224. Tests 
are performed determine whether a oonnectton is mads, stsp 226. If so, the process ends. If a connection la 
not made, a test Is perftonmed to determine whether it is the last protocol in the socket extension. If not, the 
next protocol In the extension is tasted, step 224. If all the protocols used when creating the socket have failed 
to provide the connection, the transport provUer returns a nottf ioatlon of failure to the application, step 232. 

S5 As nrkontbned prevktudy, the mventton finds use in a plurality of oomputere which are part of a network 
such as a Local Area Network or wkle Area Network. Although the specific choice of computer In these net- 
works [6 limited only by performance and storage requirements, computera in the IBM PS/2 fTM) series of 00m- 
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tho reador Is referred to Technical Reforenca Manual Pereonal Systems^ Model 50, 60 Systems IBM Corpor- 
ation, Part No. 68X2224 Ord^r Number 568X-2224 and Technical Reference Manual Personal Sv3tenfta/2 
(Model 80) IBM Corporation Part No. 68X 2256 Order Number 888X-2264. Ono oparalmg eyetem which an 
IBM PS/2 personal computer may run is ISM'S OS/2 2.0 (TM), For mor$ Information on the IBM 08/2 2,0 Op- 

5 aratlng Bystein, the reader is refarrwl to QS/2 2.Q Technical Library. Prooranfimina oulde Vol. 1, 2, 3 Version 
2.00 Order Noa. 1006291, 1006485, 1008494. In the altar native, the computer system mifiht be in the IBM 
RISC SystenVeOOO (TM) line of computers which run on the AIX (TM) operating syatem. The various models 
of the RISC System/6000 are described in many publications of the IBM Corpor^ion. for example, RlSCSys- 
tem/60Q0. 7073 and 7016 POWERatation and POWERservsr Hardware Technical reference, OnJer Na SA23- 

10 2644-00. The AIX operating system is described In General Concepts and Procedure-AlX Version 3 for RISC 
Svstem/6000 Order No. 802^2202-00 as well as other publications of the IBM Corporation. In lieu of the Cited 
references, the reader Is offered the following general description of e computer system which could be utilized 
to precttce the present invention. 

In FIG. 7, a computer 310» comprising a systsm unit 311, a keyboard 312, a mouse 313 and a display 314 

IS are deptcted. The screen 316 of display device 314 is used to piesent tfie vteual changes to the data object 
The graphical user fnkerfiBce supported t>y the operating system allow the user to use a point and shoot method 
of input by moving the pointer 315 to an loon representing a data object at a particular location on the screan 
316 and press one of the mouse buttons to perform a uaer command or selection. 

FIG. 8 shows a block diagram of the components of the computer shown In FIG. 7. The system unit 11 

20 Includes a system bus or piurallty of system buses 21 to which various components are coupled and by which 
communication between the various components is sccompfished. The microprocessor 322 is connected to 
the system bus 321 and la supported by read only memory (ROM) 323 and random access memory (RAM) 
324 also connected to system bus 321. A microprocessor In the IBM multimedia PS/2 series of computers is 
one of the Intel family of microprocessors including the 306 or 468 mioroprocessors. However, other mlcropro- 

29 cesGors included, but not llmftad to. Motorola's family of microprocessors such as the 68000, 68020 or the 
68030 microprocessors and various Reduced Instruction Set Computer (RISC) microprocessors manufactured 
by IBM, Hewlett PscKerd, Sun, Intel, Motorola and others may be used In the specific corrtputer. 

The ROM 323 contains among otharcodethe Basiclnput-Outputsystem (BIOS) which controls basic hard- 
ware operations such as the Interaction and the disk drives and the keyboard. The RAM 324 is the main memory 

30 into which the operating system, transport providers and application programs are loaded. The memory man- 
agement chip 325 is connected b the system bus 321 and controls dirsot memory access operations including, 
passing data between the RAM 324 and hard disk driva 328 and floppy disk drive 327. The CD ROM 332 Is 
also coupled to the system bus 321 . 

Also connected to the system bus 321 are various I/O contrdiers; The keyboard controller 326, the mouse 
35 controller 329. the video controfler 330. and the audio controller 331 which control their respective hardware, 
the keyboard 312, the mouse 31 3, the dlsr^ay 314 and the speaker 315. Also coupFed tn the system bua 321 
is the digital signal processor 333 which corrects the sound produced by the speaker 315 end is prefiSFably 
Incorporated into the audio oontnoller 331. An I/O controller 340 such as a Token Ring Adaptor enebles com- 
munioatk)n over a networlc 342 to other similarly configured data processing systems. 
40 While the Invention has been described with respect to parttoutar embodiments above, It will be understood 
by those skilled in the art that modifications may be macte without departing from the spirit and scope of the 
present invention. The preceding description has described the principles of the present Invention In terms of 
a particular communications endpolnt object, a sodcet, in the socket layer between the application layer and 
transport layer. The principles of the inventfon could be extended to provide similarly configured oomnnunica- 
45 tlon endpolnt objects in other layers. For example, an object In the network Interface layer could be used to 
monitor a plurality of underlaying MAC drivers to that data could be sent or received over a plurality of MAC 
protocols to different types of networks. These embodiments ere for purposes of example and illi^tratlon only 
and are not to be taken to limit the scope of the inventk>n nanrower than the scope of the appended dainr^s, 

60 

Claims 

1. A method for comrruinicating between nodes in a computer network In which a plurality of protocols are 
useable by network nodes, the method comprising the stops of: 
SS creating communication endpolnt objects defining communteation paremetsre for respective net- 

work nodes, the objects having infonmatlon about the plurality of protocols which are useable by said node 
for inter-node communication: and 
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^id nodes using a selected one of the plurality of protocols. 

2. A method according to claim 1 , wherein the selected protooot id chosdn based on u&er preferences. 

3. A method according bo daim 1 , v^hereln the selected protocol is cho&en t)ased on a capability of the se- 
lected protocol. 

4. A method according to any one of the preceding dainns, wherein the creating step comprises the steps 
of: 

requesting Information of each of the plurality of protocols; 

selecting a set of protocols from the plurality of protocola, which selected protocols are useabto hy 
the respective nodes; 

building a pratocol control block for each of the selected protoools; and, 
inserting a pointer In the corraminfcatfon endpoint object for each protocol control block of a se- 
lected protocol 

5. A method according to dalm 4, wherein (he order in which the pointers are Inserted Is based on user pref- 
erence. 

6. A n^ethod according to daim 4 wherein the selecting step comprises the steps of: 

20 detemiining whether there is a match for a first protocol for e first set of protocol parameters, the 

first protocol corresponding to a first pointer In the socket: end. 

responsive to finding no ntatch for the first protocol, determining whether the first protocol is sup- 
ported non-netively in the network. 

25 7. A system for communicating between nodes in a computer network In which a plurality of protocols are 
useable by network nodes, the system conrprleing: 

means for creating oommunlcatton endpoint objects defining communication parameters for re- 
spective network nodes, which objects have Informatksn about the plurality of protocols useable by re- 
spective computer systems each coupled to one or more nodes in the network; and, 

$0 means for establishing a connection between a first and a second computer system using a se- 

lected one of the plurality of protocols at the time communication is requested between nodes on the dif* 
ferent systems. 

6. A system according to dalm 7, whteh further comprises: 
55 mear» for selecting a set of protooda from aaU plurality of protocols; 

means tor requesting Information from each of the plurality of protooda; 
means for building a protocol control block for each of the selectod protocols; and» 
means for Inserting a pointer in the convnunlcation endpoint object for each protocd control block 
for a selected protocol. 

4d 

9. A system according to deim 6, which further comprises: 

means for determining whether there Is a match for e first protocol for a first set of protocol para- 
meters, the first protocol corresponding to a f fret pointer in the socket; and, 

means for determining, responsive to finding no match for the first protocol, whether die first pro- 
^ tocol Is supported non-natlvely In the network 



so 
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